This application claims the priority of German Patent Document 102 39 934.4, filed in Germany on Aug. 30, 2002, the disclosure of which is expressly incorporated by reference herein.
The invention relates generally to a method for controlling service engagements for the bus users in a data bus system having a resource manager and bus users using the data bus. At least one bus user provides services and other bus users use these services. The resource manager stores information about the type of the available services provided by the bus users and information about the service-providing bus users. The resource manager reserves a service from a providing bus user if the service is free and sends a response to a requesting bus user so that the requesting bus user can use the service from the providing bus user via the data bus.
Particularly in connection with telematics systems, resource managers are used in order to control a large number of services and large volumes of data. By way of example, a service may be an application program, particularly a piece of software that can be executed on a control unit. The service is preferably used by other software programs or services. In complex telematics systems, application programs called in various telematics applications are not stored a plurality of times in various components but rather once as a service program. This service program is then called a plurality of times by different control units when various programs are executed. In complex telematics systems, particular services are required very frequently, which means that the resources, i.e. the services provided, are managed. This involves recording engagement times for the services and, in the event of a request by a service user, reserving a service and preparing it for service use.
Such resource management methods are used in connection with methods of transport, for example aircraft, motor vehicles and others, and are either stored centrally in a resource control unit or are provided distributed over a plurality of control units. In connection with motor vehicles, resources of the data bus itself, i.e. its engagement and free channels and resources of the telematics system are both managed, with the telematics system being connected to the data bus in distributed form. In this case, resources of navigation systems, radio receivers, television receivers and telephone-linked diagnostic and software systems are managed.
Such resource management methods are typically used in connection with telematics data buses. Alternatively, a resource management system can be used with conventional data buses, for example with a CAN or LIN data bus. To provide a better understanding of the rest of the description, a brief description of the MOST data bus used in motor vehicles is given as an example of a telematics data bus. Data transmission via the MOST data bus is divided into frames having a length of 64 bytes. Of these, the first and last bytes are used for administrative purposes at bus level. The remaining bytes are assigned to an area for synchronous channels, to an area for asynchronous data transmission and to a control channel with 2 bytes. The synchronous channels are used to transmit synchronous data, for example audio data and video data. The asynchronous area is used for packet-oriented data transmission. The control bytes of the control channel interact with other control bytes in the other frames. The control bytes are evaluated in order to interchange control messages between the devices on the MOST bus. The frames are message blocks recurring cyclically at a frame frequency. Synchronous and asynchronous areas can be used for the different resources according to requirements. By way of example, synchronous channels can also be clustered for television transmission.
On the basis of the MOST Specification Framework, section 6.0 “MOST Frame structure”, synchronous data channels for connecting a source (e.g., CD player) and a sink (e.g., amplifier) are provided for as long as a synchronous channel is open. The synchronous and asynchronous channels are controlled using the control channel. A piece of software in one of the control units sends a control message to the devices which are involved, in order to connect the data source to the new data sink. The other MOST functions are also addressed using the control channel.
In the case of the MOST data bus and similar data bus systems, resource managers are used in order to manage all the resources of the data bus system itself, including management of the synchronous and asynchronous channels and their sides, and the resources of the functions provided via the data bus. The resource manager knows all the resources of the system that need to be managed. The resource manager is the central management unit for the resources of the data bus system. In addition, the resource manager monitors and observes current resource use and knows the services that are not currently being used. As soon as an application function calls one of the resources, for example services, functions or initialization parameters, from the resource manager, the resource manager enables the service if use of the service is possible or permitted. This involves taking into account priority levels and service accessibility, for example. If the calling function has low priority or if no provision is made for the service to be accessed, then the resource manager also rejects access.
It is an object of the present invention to specify a system and method for controlling the service engagement in a data bus system which controls the resources, the service engagement and/or the service allocation in complex data bus systems having synchronous and asynchronous functions.
In a first embodiment of the present invention, information about the provided services is provided on the data bus by the bus users via a standard interface. The change in the provision of a service from a bus user is made available to the resource manager via the standard interface. The resource manager controls the service engagement on the basis of a priority information item that is transmitted to the resource manager in a message (request or notification) from a requesting bus user, for example. The priority information item does not necessarily have to be transmitted with a resource request. Alternatively, an application can also send its resource request to the resource manager with an application identifier, and the resource manager can send a request to the priority manager, which knows the current overall system state and takes it as a basis for assigning a priority to the resource request using the application identifier. The priority manager then notifies the resource manager of the priority, and the resource manager engages the services on the basis of the priority information.
The standard interface allows data interchange between any desired functions which call a service and the resource manager. All resource requests are sent to the resource manager's interface. This can involve functions using the data bus to send a request to the resource manager's interface. Since all requests are sent to the resource manager's interface, the resource manager can easily record the use of the services and the engagement time. The resource manager can then take the current resource engagement or the current resource requests as a basis for deciding whether a particular function is granted or refused a service or whether the request is put into a queuing loop.
The resource manager preferably knows all of the resources that are available in the system. In order to have information about the resources of the resource manager, the startup of the data bus involves recording every function block which provides resources, and this involves compiling information regarding which resources can be provided by a function block. In addition, it is possible to establish which requests and/or which associated priority are provided for a function block.
Every resource or every service is made available to the system via a controlling function block in a standard manner. For synchronous resources, the interface preferably has special interface functions that are used in this connection.
The resource manager can control the engagement of the data channels within a frame, for example using the service “engagement of data channel n”. By way of example, the resource manager can assign individual synchronous data channels within a frame to one or more bus users using them.
The service-providing bus users preferably have a standard interface that can be used to check the information relating to the services from the resource manager or from the rest of the bus users. The interface between the data bus and a service-providing bus user has data formats for information that indicates the number and type of the services. It is also possible to transmit the maximum number of service users per service at one time.
In a second embodiment of the present invention, information about the provided services is provided on the data bus by the bus users via a standard interface. A change in the provision of a service by a bus user is made available to the resource manager via the standard interface, so that the resource manager controls services that relate to functions of the bus users themselves.
In contrast to the first embodiment, this resource management method does not involve controlling the channels of the data bus and services linked thereto, but rather involves the control of services from individual bus users on the data bus. In particular, services of a distributed telematics system are controlled and, in so doing, particularly the services of the individual telematics components. This can also involve management of the association between a data sink and a data source in relation to a synchronous data bus channel.
Alternatively, the method in accordance with the first preferred embodiment (i.e., management of the data-bus-related resources) can be combined with the method in accordance with the second embodiment (i.e., management of the resources of the bus users in the telematics system).
By way of example, for the “amplifier engagement” function, a telephone and a radio can be connected simultaneously. In another embodiment of the present invention, the message transmission need for each individual bus user on the data bus can be requested or estimated.
Beyond the actual data bus management function, the resource manager preferably cooperates closely with services of the telematics system. Every piece of software that can be called in the telematics system, i.e., which can be called by other application functions, is stored in the resource manager, so that the resource manager has a list of all the services of the telematics system available. If a function accesses a service, the resource manager collects information about this service and establishes the service's storage location, for example on a first control unit at a particular storage location. The synchronous data bus resources are treated in a specific way. Since the data bus itself usually has functions available for stipulating or connecting synchronous data channels to synchronous resources, the resource manager often uses the functions already available in the data bus system.
The resource manager is informed about changes in the services by the service-providing bus users. Service-requesting bus users send their request to the resource manager. For each request, the bus users communicate the requested resources and possibly also the priority of the request. The resource manager decides about the allocation of the requested services on the basis of the availability and on the basis of the priority of the request.
A resource conflict arises when a requested resource has already been engaged. The resource conflict is resolved by the resource manager. If the priority of the current request is higher than the priority of the bus user which is already a user, the service's existing engagement is cancelled and the service can be engaged for the requesting bus user by the resource manager. If the priority of the current request is lower than or the same as the priority of the bus user which is already a user, the bus user's request is rejected by the resource manager or is entered into the list of already existing requests in order. A requesting bus user can indicate whether it needs to be put into a waiting list if the service is engaged.
Each resource is preferably provided on the resource manager's interface by the resource-providing function block in a standard manner. By way of example, existing interface functions can be used for synchronous resources of the data bus. For other resources, functions such as a resource counter, resource info, resource conflict, stipulate resources, remove resources, and resource use can be provided. The resource manager preferably has an error-handling algorithm that can also be used to take care of functions and service requests that have incorrectly not been transmitted to the resource manager's interface. One option for an error-handling routine involves the resource manager monitoring the use of all the resources and establishing whether a correct service request exists therefor. The resource manager can then immediately stop dubious resource engagements.
Provision can be made for the resource manager not to know the user of a service, for example the bus user making the resource request. This requirement allows flexible and expandable resource management. The resource manager produces an explicit designation on the basis of a resource request. This designation is used for explicitly linking a service to a requesting bus user. Normally, however, the resource manager has no direct association with the real bus user, which means that the resource manager's information cannot be used to infer real devices. This has the advantage that there is an increased data security level on the telematics system. This behavior has nothing to do with data security, but rather increases the system's openness and flexibility. The resource manager does not need to know applications using resources. For example they can be introduced into a system retrospectively.
An application program (application) which requests resources or services from the resource manager transfers with the request a list of the services or resources required and possibly a priority for each request. On the basis of the existing requests, the resource manager then enables the services for the requesting application programs on the basis of the associated priorities.
The resource manager can be in the form of a function block, for example. In connection with the MOST data bus system, the resource manager can be implemented as an “Fblock”. A MOST FBlock can be implemented in every bus user on the MOST data bus. This results in a very high level of flexibility, and available tools for producing such FBlock functions of the MOST can be used. The resource manager can be programmable and can be moved flexibly from one bus user to the other.
A more complete understanding of the present invention will be afforded to those skilled in the art, as well as a realization of additional advantages and objects thereof, by a consideration of the following detailed description of the drawings. Reference will be made to the appended sheets of drawings, which will first be described briefly.